Vehicles (e.g., spacecraft, aerial vehicles, etc.) sometimes utilize an Inertial Measurement Unit (IMU) for calculating a position or attitude of the vehicle. IMU is often used interchangeably with Inertial Reference Unit (IRU), and any discussion of an IMU described herein may also refer to an IRU. An IMU or an IRU may include any combination of accelerometers, magnetometers, and/or gyroscopes as a matter of design choice. An IMU and/or an IRU generate attitude data regarding the vehicle's velocity, orientation, and gravitational forces using a combination of accelerometers, and/or gyroscopes, and/or magnetometers, etc. A computer may then calculate the current position of the vehicle by integrating over time the attitude data generated by the IMU. In some cases, the computer and the IMU operate asynchronously with respect to each other, which may cause problems in determining the current position of the vehicle accurately.
For instance, a satellite computer may utilize one reference clock to read samples of attitude data from the IMU, while the IMU may utilize a different reference clock to generate updates to the attitude data. In this case the IMU update to the attitude data occurs at one moment in time while the satellite computer sample of the attitude data occurs at another moment in time. The result is a time lag. If the time lag is constant, then this may be compensated for by the satellite computer. However, when the satellite computer and the IMU operate asynchronously with respect to each other, then the time lag varies over time. This may cause problems when the attitude data is changing dynamically. For instance, if the satellite is experiencing dynamic motions, then the time lag may introduce errors in the integrated solution of the IMU output data that is used by the satellite computer to calculate a current position of the vehicle. Further, the time lag may cause problems when the IMU data is correlated back to other positional data systems. For example, a satellite may use non-IMU positional information such as star trackers to generate positional information for the satellite, which is then used to correct the IMU calculated position. However, a dynamically changing time lag in the IMU attitude data can make this process less accurate.
In some applications, various active processes may be used to synchronize the sampling clock of the satellite computer with the update clock of the IMU. For example, when the satellite computer and the IMU communicate over an asynchronous Mil-STD 1553 data bus, synchronization mode code broadcast messages may be generated by the satellite computer for devices on the bus, which will ideally prompt the devices to reset (or set) their respective internal clocks based on the broadcast. However, not all 1553 bus devices support synchronization mode code broadcast messages, and such support may be vendor specific. Further, generating synchronization mode code broadcast messages may have unintended consequences when devices do not fully support such broadcast messages. In addition, broadcast messages utilize bandwidth on the bus, which may not be available. While external synchronization lines may be used in some cases, this adds complexity and introduces possible points of failure.